上一講我們評比了不同種類的部落格平台，從網站效能、建置效率、上手門檻等不同維度來比較。
雖然靜態網站框架的上手門檻普遍較高，但是有網站效能最佳、成本最低的這些特性，且身為工程師想多點彈性來搞點花樣，因此我最後選擇了靜態網站作為架設部落格的類型。
所謂靜態網站的框架有一種更專職的稱呼方式：Static Site Generator（靜態網站產生器），簡寫為 SSG，其主要目的就是將使用者的原檔（如 Markdown）透過 Template 產出 HTML 的檔案。
這一講就來聊聊各種 SSG 有哪些優缺點，我們該怎麼挑？在此之前，我們先來聊聊什麼時候有 SSG 的，從剛開始出現到現在，經歷了哪些變化？
在大約 2007 的時候，正值 Web 2.0 高峰，當時比較盛行的網站類型是所謂的「動態網站」，例如 WordPress 和 Drupal 的等等。這些網站都需要資料庫，並透過 Java、PHP 所撰寫的網頁伺服器來讀取資料庫，動態生成 HTML。
此時 GitHub 釋出一個免費的靜態網站託管服務：GitHub Pages，能讓使用者「Push 即部署」，將 HTML 丟到 GitHub 後便直接能公開瀏覽，這在開源專案上，對一些文件、Demo 類的內容在部署上簡單方便了許多。
不過人們能需要自己寫 HTML，要寫一些巢狀的標籤對於純內容來說還是麻煩了些，而使用 FrontPage 或是 Dreamweaver 這類 WYSIWYG（所見即所得）軟體所產出的 HTML 來說，又顯得太冗長，會產生許多冗餘的標籤，這對於用 Git 的版控來說，其核心 Diff 的使用上就變得沒那方便。
為了讓內容的撰寫更單純，又能滿足直接產出 HTML 的需求，在 2008 年的時候 GitHub 的 CEO Tom Preston-Werner 釋出了 Jekyll：一個能絲滑的將文字內容轉成靜態網站的框架。
*初代 Jekyll 官方網站 - Internet Archive on 2009
Jekyll 引入了 Front matter 和 Blog aware 兩個概念，其中 Front matter 讓 Markdown 文件開頭使用 YAML 格式來定義一些 Meta 資料（如標題、分類等等），而 Blog aware 則表示 Jekyll 能自動從 Meta 找出時間順序、分類和標籤等，產出合理的頁面（如最新的文章排序在首位）。
所以在當時，如果你想寫部落格，透過 Jekyll 就能幫你把文章自動產成 HTML，再透過 Git Push 在 GitHub Page 上顯示。
在 Jekyll 流行幾年之後，大家發現用 Ruby 所撰寫的 Jekyll 有些明顯的缺點，像是其單執行緒的架構，在文章數變多之後建置的速度就變得很慢，Ruby 的安裝也相較其他語言來說較為麻煩。
在 2012 年來自台灣的 Tommy Chen 就用 Node.js 開發 Hexo（作者介紹 Hexo 的首篇文章），大幅加速了建置的速度，也對中文有更高的支援度。
之後的 2013 年，現在依然相當熱門的 Hugo 誕生，作者 Steve Francia 使用擅長平行運算的 Go 所撰寫，使得數千篇文章得以在幾秒的等級內建置完成。
而這些框架的概念都是在建置階段把純 HTML 產生出來，將前後端完全分離，把主要內容透過預建置的方式產出 HTML，就不用額外的資料庫來存取這些內容。
在 2016 年這樣的概念被 Netlify 的創辦人 Mathias Biilmann 提出並且命名成 Jamstack，J 表示 JavaScript，表達在前端的互動邏輯；A 表示 API，意謂透過 API 取得動態資料（如留言、天氣資訊等非主要內容之資料）；M 表示 Markup，也就是將主要內容先轉譯成 HTML（一種 Markup 語言）。
Jamstack 的核心就是將主要內容先產生成 HTML，有需要再動態取得其他資料。也由於內容都變成靜態的 HTML 形式，這樣的架構能讓讀取快速，也容易擴展、適合部署在 CDN 上；少了主要的後端伺服器，不但花費、維護成本降低，安全性也相對提高了不少。
除此之外，前端框架如 Angular、React、Vue 的興起也更加深 Jamstack 中 J 的部分，這些前端框架讓開發具有互動性的網頁變得更加容易，像是在 2015 年一款叫做 Gatsby 的 SSG，就首度納入 React 到其架構中，讓工程師可以用 React 寫 Code 並且產生出靜態 HTML；2016 年出現了 Next.js，一款 React 應用型框架，不但可以支援 SSR（Server-Side Rendering），也能當作 SSG。
*Jamstack Site Generators 頁面截圖
我們可以在 Jamstack 的網站中看看目前有哪些符合此架構的框架，截至今年（2025），SSG 的列表已經成長至 300 多個框架了。
在 React 及 Vue 等前端框架紅了好幾年之後，2020 年左右大家開始發現這些框架越來越肥，一些想要能簡單互動，但以內容為主的來開發網站的人，因為用了 React 或 Vue 來寫 Code，例如 Gatsby、Next.js、VuePress 這類 SSG，在第一次載入網頁時會將整包前端 Library 也載入。
好死不死，2021 年的時候 Google 將前一年所制定的 CWV（前面所提到的 Core Web Vitals，衡量網站效能的指標）正式納入其搜尋引擎的排名演算法中，這個分數如果表現得不好，搜尋排名就會變差，那麼流量、廣告收入也就會降低。
SSG 雖然已經能將主要內容轉成 HTML，從而快速在瀏覽器中載入。但基本的 HTML 是靜態的，為了增加互動性，需要額外載入 JavaScript，一大包的 Library 會降低 CWV 中 LCP 的分數（首次載入時間）。
而為了要互動，HTML 的 DOM 需要和 JavaScript 綁定，這個動作稱為 Hydration。其成本是高的，因為要佔用 Main thread 來執行 JavaScript 的程式碼，要能夠互動需要一直到元件和事件綁定、邏輯註冊等事情完成。
也就是說，如果畫面中有某個按鈕，要等到其他元件也都 Ready，Hydration 完成，才能夠被點擊。如此一來，CWV 中的 INP 分數就會低，影響到整體得分。為了解決 CWV 影響 SEO 這類的問題，許多 SSG 框架都在嘗試新方法。
到了 2022 年中，一款稱作 Astro，測試了一年左右的 SSG 在其 v1.0 版本中提出了叫做 Island 的架構，預設整個頁面只輸出純粹的 HTML，只有特別被標註的元件「局部」的使用 JavaScript。因為將整個頁面拆成多個局部的行為，所以此架構才被稱作 Island。
在同一年底，Next.js 也由於過於肥大的問題，走了類似的路線：Partial Hydration，從整頁都是 React，拆成有需要的互動才和 Server 拿對應的 JavaScript 並綁定。
此後，既想保持頁面載入效率高、又兼備一定互動性的 Hybrid 時代正式到來。
在 SSG 的演化簡史當中，我們可以發現因應社群中的不同需求，出現了千奇百怪的 SSG。許多框架已經成了歷史的眼淚而乏人問津，但有些還是經過不斷的修改依然保持一定的使用者。
我觀察如今的 SSG 使用者，大致可以分成以下幾種群體及其對應使用的框架
你想挑選的 Static Site Generator 需求是什麼呢？
就我而言，要刻出一個部落格，主要還是以內容為主、互動為輔。如此一來 Hugo 和 Astro 這類型的框架就成為我考慮的目標。Hugo 在建置速度上比 Astro 快上不少，然而 Astro 在互動情境上則較為優秀，不但有官方整合的 React 和 Vue，Island 的架構也能讓互動時的 CWV 保持高分。
對於比較熟悉 React 的我來說，同時又想做點互動元件、寫些小工具在部落格上，Astro 則是我目前的首選，雖然門檻相較我原本使用的 Hexo 高一些，但其效能高、有互動性，還能用熱門框架來寫。
iThome鐵人賽
看影片追技術